32nd  Annual  Precise  Time  and  Time  Interval  (PTTI)  Meeting 


THE  INFUSION  OF  MCS  KALMAN  FILTER 
DATA  INTO  GPS  BLOCK  II/IIA  FREQUENCY 
STANDARD  ANALYSIS  TECHNIQUES 


Gary  L.  Dieter,  Gregory  E.  Hatten,  and  Jack  Taylor 
Boeing  Space  and  Communication  Services 
440  Discover  Avenue,  Suite  38 
Schriever  Air  Force  Base,  CO  80912-443 8,  USA 
Tel:  (719)  567-3176,  (719)  567-2943,  (719)  567-5953 
E-mail:  Gary.L.Dieter@Boeing.com,  Gregory.E.Hatten@Boeing.com, 

Jack.  Taylor2@Boeing.  com 


Abstract 

Recent  advances  have  allowed  Boeing  GPS  navigation  payload  analysts  the  ability  to  transfer, 
archive,  and  manipulate  Master  Control  Station  (MCS)  Kalman  filter  data .  Previously,  access  to 
these  data  was  cumbersome  and  restricted  to  a  limited  timespan .  The  new  data  retrieval  process 
has  proven  to  be  useful  in  many  areas  of  GPS  analysis,  including  frequency  standard  performance 
characterization .  Both  routine  and  anomolous  frequency  standard  performance  analysis  techniques 
are  enhanced  by  considering  the  characteristics  and  trends  of  key  MCS  filter  variables , 

This  paper  describes  the  methodology  by  which  the  MCS  Kalman  filter  data  is  attained .  It  also 
examines  situations  in  which  MCS  Kalman  filter  clock  state  estimates  and  navigation  performance 
metrics  have  proven  to  be  useful  in  analyzing  frequency  standard  performance .  Examples  include 
routine  examination  of  frequency  standard  stability  using  MCS  phase  offset  estimates,  analysis  of 
MCS  frequency  offset  estimates  before  and  after  a  “ clock  q-bump,”  and  comparison  of  MCS  clock 
state  estimates  versus  those  of  the  National  Images  and  Mapping  Agency  (NIMA).  Conclusions 
reveal  that  new,  valuable  insight  is  gained  by  considering  MCS  Kalman  filter  data  when  petforming 
frequency  standard  analysis. 


MCS  KALMAN  FILTER  DATA  TRANSFER  METHODOLOGY 


Until  the  summer  of  1999,  analysis  of  GPS  Kalman  filter  data  was  limited  to  on-line  tools.  Because  of 
security  constraints  and  the  awkwardness  of  the  Jovial-based  architecture,  the  ability  to  move  data  off-line 
and  employ  COTS  analysis  tools  was  labor-intensive  and,  in  practice,  rarely  done.  Instead,  most  analysis 
was  done  on-line  and  in  real-time.  The  on-line  tools  are  relatively  effective  in  spotting  and  analyzing 
anomalies  as  they  occur,  but  any  additional  analysis  often  has  to  be  performed  by  outside  agencies. 

Beginning  in  the  summer  of  1999,  Boeing  personnel  working  at  the  MCS  began  retrieving  selected  MCS 
data  from  the  on-line  system  and  archiving  it  off-line.  This  method  of  archiving  data  allowed  much 
greater  flexibility  for  analysis.  COTS  tools  such  as  Stable32  and  MS  Excel  could  be  used  to  analyze  and 
graphically  display  the  data.  Also,  time  spans  are  limited  only  by  the  beginning  of  this  archive.  Many 
on-line  tools  are  restricted  to  accessing  data  from  the  last  48  -  72  hours.  Even  MCS  tapes  containing 
stored  data  are  erased  within  6  months. 

The  data  retrieval  activity  is  a  three-step  process.  First,  one  or  more  batch  scripts  are  run  on  the  standby 
mission  package.  The  standby  mission  package  is  identical  to  the  active  mission  package,  and  is  kept  in  a 
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COTS  analysis  tools. 

Clearly,  the  process  would  be  improved  by  automation.  Boeing  personnel,  in  conjunction  with  the  Air 
Force  and  other  GPS  contractors,  are  trying  to  streamline  the  process.  Several  issues  remain  to  be 
addressed.  Security  is  a  major  issue.  Several  aspects  of  the  GPS  mission  package  are  classified.  Any 
scheme  to  remove  data  (even  unclassified  data)  from  a  classified  system  requires  extensive  security 
reviews.  Several  means  of  removing  the  data  from  the  system  have  been  rejected  for  security  reasons. 
Our  ultimate  goal  is  to  have  the  additional  MCS  data  automatically  downloaded  to  the  Integrated  Mission 
Operations  Support  Center  (IMOSC)  terminals,  where  an  ensemble  of  Windows-based  analysis  tools  will 
reside. 

The  advanced  age  and  complexity  of  the  MCS  Legacy  system  is  another  difficult  issue.  The  Air  Force  is 
trying  to  move  MCS  operations  to  a  newer,  more  advanced  system.  This  makes  it  very  difficult  to 
commit  resources  to  upgrading  the  older.  Legacy  system.  Although  the  new  system  is  not  expected  to  be 
delivered  for  several  years,  few  MCS  Operational  Control  System  (OCS)  resources  are  devoted  to  the 
outgoing  Legacy  system.  Despite  these  challenges,  the  authors  believe  that  the  data  retrieval  and  archival 
process  can  be  streamlined  and  that  this  valuable  effort  will  continue. 

Currently,  18  files  are  transferred  on  a  daily  basis.  This  list  of  files  contains  the  following  data:  Kalman 
state  estimates  (including  backup  and  KF  maintenance  activities);  reference  trajectory  data  and  coordinate 
system  (ECI-ECEF)  transformation  data;  GPS-UTC  steering  activity;  smoothed  measurements  and 
residuals;  navigation  message  upload  data;  and  performance  monitoring  data  (Estimated  Range 
Deviations  (ERDs),  Observed  Range  Deviations  (ORDs);  and  navigation  solution  (NAVSOL)  data). 

ROUTINE  DATA  ANALYSIS 

Transferred  MCS  data,  along  with  downloaded  NIMA  ephemeris  and  clock  data,  and  published  Notice 
Advisories  to  NAVSTAR  Users  (NANUs),  are  combined  to  generate  3  groups  of  periodic  reports: 
weekly,  monthly,  and  quarterly. 

The  weekly  report  consists  of  an  upload  count  plot  (see  Figure  1),  which  shows  the  number  of  navigation 
uploads  transmitted  to  each  SV  over  the  previous  week.  A  health  scan  is  also  done,  and  only  those 
uploads  transmitted  while  the  SV  was  healthy  are  counted.  This  report  grew  out  of  a  contingency  upload 
list  which  formerly  was  manually  transcribed  from  crew  Payload  Systems  Operator  (PSO)  log  records. 
Reasons  for  excessive  uploads  are  listed  on  the  chart.  Typical  reasons  for  additional  uploads  include  AFS 
instability,  momentum  dumps,and  eclipse  season  operations. 

Weekly  ERD  plots  (see  Figure  2)  are  used  to  investigate  reasons  for  extra  uploads.  These  charts  are 
compiled  weekly,  but  not  distributed  due  to  their  large  file  size. 
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Monthly  reports  include  a  constellation  ERD  summary,  an  upload  count  summary,  an  upload  aging 
summaiy,  and  a  NIMA  vs.  MCS  clock  stability  comparison  chart.  The  ERD  summary  chart  (Figure  3) 
lists  an  average  daily  RMS  value  for  the  constellation  (both  with  and  without  GPS  IIR  SVs  included), 
along  with  a  monthly  average  daily  RMS  summary  by  SV.  Finally,  notes  describe  the  poorest  and  best 
performers  in  the  GPS  constellation. 

The  monthly  upload  summary  (Figure  4)  shows  the  average  number  of  uploads  per  day  (while  SVs  are 
healthy)  for  the  entire  constellation  for  the  past  6  months.  Also  included  in  this  report  are  the  daily 
upload  statistics  for  each  SV  for  the  current  and  previous  months.  A  table  at  the  bottom  lists  SV  outages. 

Monthly  upload  aging  plots  (Figure  5)  are  compiled  each  month  for  each  SV  over  a  two-week  and  60-day 
duration  for  the  period  2,  months  prior  to  the  current  month.  In  these  reports,  every  upload  built  for 
each  SV  for  the  month  is  reconstructed  and  compared  to  NIMA  precise  ephemeris  and  clock  data.  Mean 
uploads  for  each  SV  are  plotted.  Over  6,000,000  data  points  are  processed  each  month  to  generate  the 
upload  aging  report.  [1] 

The  NIMA  vs.  MCS  comparison  report  is  also  accomplished  on  a  monthly  basis.  This  report  compares 
the  stability  (Hadamard  deviation)  of  the  MCS  Kalman  clock  phase  estimates  with  the  phase  estimates 
derived  through  NIMA  post-processing.  This  check  is  accomplished  on  a  Windows-PC  platform  using 
Stable32  developed  Hamilton  Technical  Services.  Three  examples  are  discussed  in  more  detail  in  the 
next  section. 

In  addition  to  weekly  and  monthly  reports,  the  quarterly  reports  contain  a  90-day  ERD  summary  for  each 
SV  (average  and  RMS  daily  statistics),  and  an  overall  ERD  summary  (see  Figures  6  &  7). 

RESULTS  OF  DATA  ANALYSIS 

NIMA  Vs.  Kalman  Comparison 

Figure  8  is  an  example  of  a  "good"  stability  comparison  between  NIMA  and  MCS  Kalman  data.  In  this 
case,  the  Hadamard  deviation  plots  line  up  on  top  of  each  other  for  x  >  2000s.  For  x  <  2000s,  there  is 
some  divergence,  but  as  this  occurs  for  every  satellite  in  the  GPS  constellation,  it  is  assumed  that  this  is 
due  to  processing  differences  between  the  MCS  and  NIMA. 

Figure  9  is  an  example  of  a  "poor"  comparison  between  NIMA  and  MCS  Kalman  data.  In  this  case,  the 
phase  data  supplied  by  the  MCS  Kalman  filter  indicates  a  more  stable  clock  than  NIMA's  phase  data. 
This  is  due  to  the  process  noise  values  (Q's)  that  are  specific  to  that  particular  clock.  As  a  clock's 
characteristics  change  over  time,  the  process  noise  values  are  periodically  updated.  Since  new  process 
noise  values  are  derived  approximately  once  per  quarter,  it  is  possible  that  a  frequency  standard's  current 
performance  characteristics  can  be  different  than  the  performance  characteristics  as  measured  several 
months  ago. 

Figure  10  is  an  example  of  intentional  clock-ephemeris  "cross  corruption”  of  MCS  Kalman  filter  states. 
In  this  case,  the  frequency  standard  has  known,  time-dependent,  periodic  behavior.  Since  the  MCS 
Kalman  filter  can  not  model  periodic  behavior  in  the  clock  states,  the  process  noise  values  (Q's)  are  set 
artificially  tight.  In  this  manner,  periodic  behavior  in  the  clock  states  is  transferred  to  the  ephemeris 
states.  Although  this  results  in  the  separate  ephemeris  and  clock  states  being  modeled  improperly,  the 
combination  results  in  a  more  accurate  navigation  solution. 
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SVN  19  Frequency  Step  Analysis 


On  May  25,  2000,  SVN  19's  Cesium  Frequency  Standard  #3  experienced  a  frequency  offset  shift  of 
approximately  2E-12  s/s.  Frequency  jumps,  although  not  common,  are  on-orbit  anomalies  that  2  SOPS 
operators  expect  from  time  to  time.  Although  there  is  nothing  that  2  SOPS  can  do  from  a  hardware 
perspective  to  minimize  the  effect  of  such  perturbations,  proper  MCS  Kalman  filter  maintenance  can 
ensure  a  minimal  impact  on  navigation  signal  accuracy,  as  well  as  on  the  MCS  crew  workload. 

Each  satellite’s  process  noise  values  (Q’s)  are  optimised  for  day-to-day  operations,  and  do  not  take 
anomalous  behavior  such  as  frequency  steps  into  consideration.  In  the  case  just  described,  it  is  the  job  of 
2  SOPS  analysts  to  adjust  the  filter  to  allow  for  the  frequency  step.  This  is  accomplished  by  re¬ 
initializing  the  clock  process  noise  to  a  database  value.  This  procedure  is  known  as  a  clock  "Q-bumpf 

The  transferred  Kalman  data,  along  with  a  set  of  "truth"  data  (in  this  case  post-processed  NIMA  data), 
provides  valuable  insight  into  this  anomaly,  its  effects,  and  the  2  SOPS  corrective  action  taken.  Figure  1 1 
shows  a  plot  of  the  phase-derived  NIMA  frequency  offset  estimates  for  SVN  19  during  the  timeframe  of 
the  frequency  step.  As  seen  in  the  figure,  the  frequency  offset  shifted  at  approximately  18:00  Z  on 
5/25/00.  Also  seen  in  this  figure  is  the  MCS  Kalman  filter  frequency  offset  estimate  before  any  filter 
maintenance  was  performed  (Pre-Q-Bump).  It  is  seen  that  the  MCS  filter  frequency  offset  estimate  did 
not  react  instantaneously  to  the  frequency  step  (as  discussed,  the  filter  is  designed  for  prediction  purposes, 
and  nominally  does  not  expect  a  sudden  shift  in  frequency).  Once  MCS  operators  observed  the  problem, 
a  clock  state  Q-bump  was  performed.  The  figure  shows  how  the  filter  adjusted  its  frequency  offset 
estimate  to  fall  in  line  with  what  actually  occurred  on  the  spacecraft. 

Figure  12  shows  not  only  the  NIMA  (non-phase-derived,  in  this  case)  and  MCS  frequency  offset 
estimates,  but  also  how  the  MCS  mismodeling  affected  the  navigation  signal.  It  is  clearly  seen  that  SVN 
19's  navigation  signal  accuracy  was  degraded  during  the  period  of  misestimation,  and  the  MCS  crews 
were  kept  busy  re-uploading  the  navigation  message.  (New  uploads  appear  as  downward  spikes  in  ERD 
data.)  However,  it  is  also  seen  that  once  the  clock  Q-bump  was  perfonned  and  the  spacecraft  was 
uploaded  with  an  adjusted  navigation  message,  the  ERD  runoff  was  much  less  severe,  and  eventually 
performance  returned  to  normal.  This  careful  post-anomaly  analysis  allows  us  to  refine  operational 
recommendations  and  procedures  to  minimize  navigation  signal  accuracy  and  GPS  crew  impacts. 


SVN  22  C-Field  Tune  Analysis 


The  current  operational  method  of  changing  a  GPS  frequency  standard's  output  frequency  is  to  tune  its  C- 
field.  After  a  C-field  tune  is  commanded,  the  previous  MCS  Kalman  filter  estimate  of  the  clock  frequency 
is  incorrect,  and  a  ranging  error  runoff  will  occur,  to  correct  this  error,  2  SOPS  operators  use  navigation 
signal  data  collected  at  the  MCS  monitor  stations  to  calculate  the  new  clock  frequency  and  update  the 
Kalman  filter's  state  estimates. 

Figure  13  shows  data  from  a  C-field  tune  which  occured  on  SVN  22’s  Rubidium  Frequency  Standard  #1 
on  6/15/00.  As  is  typical  in  the  case  of  a  C-field  tune,  the  spacecraft  was  set  unhealthy  to  users  (this 
timeframe  can  be  seen  as  the  shaded  area  in  the  figure).  In  this  case,  one  can  observe  from  comparing 
NIMA  frequency  offset  estimates  to  MCS  Kalman  filter  estimates  that  the  MCS  estimate  was  not  optimal 
at  the  conclusion  of  the  C-field  tune  and  associated  filter  maintenance.  Although  the  MCS  estimate  was 
close  enough  that  the  spacecraft  could  be  set  healthy,  several  additional  navigation  message  updates  were 
necessary  during  the  first  couple  days  following  the  event.  ERD  levels  did  not  stay  consistently  low  until 
the  MCS  estimate  caught  up  with  the  actual  frequency  offset. 
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CONCLUSION 


The  ability  to  transfer  Kalman  filter  data  from  the  MCS  to  an  offline  system  has  proven  to  be  extremely 
valuable  to  Boeing  navigation  payload  analysts.  This  capability  has  provided  insight  into  many  aspects  of 
GPS  navigation  payload  analysis,  including  frequency  standard  trending  and  anomaly  resolution. 
Although  the  transfer  process  is  currently  fairly  cumbersome,  plans  for  the  future  include  an  emphasis  on 
ease  of  use  and  automation.  It  is  hoped  that  the  continued  utilization  and  refinement  of  this  data  transfer 
process  will  assist  Boeing  in  not  only  improving  frequency  standard  analysis  techniques,  but  in 
continuing  to  provide  2  SOPS  and  the  user  community  the  best  overall  GPS  support  possible. 
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RMS  ERD  Average  (Meters) 


GPS  Navigation  Performance 


(As  exhibited  by  Estimated  Range  Deviation) 
August  2000  - 1  Year  Performance 


Aug  Sep  Oct  Nov  Dec  Jan  Feb  Mar  Apr  May  Jun  Jui  Aug 

*  NOTES 

1  -  System  Spec,  is  6.0m  User  Range  Error  -This  is  not  the  same  as  SV  Estimated  Range  Deviation. 

-  Constellation  Value  for  Monthly  Average  derived  from  Average  of  Daily  RMS. 

-  July's  Constellation  ERD  performance  stayed  approximately  the  same  as  it  was  the  previous 
month  (improved  1%);  1  year  performance  was  degraded  by  about  1%  from  the  previous  month. 

-2  SVs  exhibited  RMS  Average  Daily  ERD  values  above  2.0  m:  SVN15  experienced  ephemeris  issues 
which  affected  ERD  performance  (Glint  season);  SVN17  has  relatively  poor  1-day  stability  (2.01E-13). 

-  4  SVs  exhibited  RMS  Daily  Avg  ERD  values  at  or  below  1.0  m  (43,37 ,26,34). 

-  SVN16  is  awaiting  disposal  as  of  July  27, 2000. 

-  SVN44  was  welcomed  to  the  GPS  constellation  as  an  operational  asset  as  of  August  17, 2000. 

Figure  3 .  Monthly  Navigation  Performance  Chart. 
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GPS  Upload  Count  Summary  - 

Uploads  per  Day  (Adjusted  for  data  outages) 
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Monthly  Upload  Data  for  August,  2000 


H  Jul-00 


Aug-00 


X  1.75 


0.75 


a. 


Outage  Summary  for  August,  2000: 

SV  Outage  Hrs  (This  Mo  )  Availability  (This  Mo )  Reason 


SVN13 

08/09/00  06. 11  -  08/09/00  1 0.31 

43 

99.42% 

Defta-V 

SVN26 

08/01  /00  05.55  -  08/01  /00  1 1  *21 

54 

99  27% 

Defta-V 

SVN29 

08/24/00  1 6  45  -  08/24/00  22  33 

58 

99  22% 

IPO  w/BB  Reset 

SVN44 

01  /01  /GO  00.00  -  08/1 7/00  1 3  51 

- 

100 00% 

Initial  Operational  Capability 

Blk  ll/IIA  Availability:  99.91%  fl)  Constellation  Availability:  99.92%  (*2) 

*1  -  SVN16  excluded  from  availability  statistics;  offline  since  July;  awaiting  disposal. 
*2  -  SVN44  only  counted  since  operational  (8/24/00  22:33). 


Figure  4.  Monthly  Upload  Count  Chart. 
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Hadamard  Deviation 


26 


Frequency  Offset  (s/s) 


SVN2 2  07/2000  Frequency  Stability 

£•12 


E-1  3 


E-1  4 

1  E  +  02  1  E  +  03  1  E  +  04  1  E  +  OS  1  E  +  06 

Seconds 

Figure  9.  Example  of  “poor”  NIMA  vs.  MCS  stability  comparison. 


SVN36  07/2000  Frequency  Stability 


Figure  10.  Example  of  MCS  “cross-corruption”. 


1  90E-11 

1  70E-11 

150E-11 

1  30E-11 
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7  OOE-12 

5  OOE-12 

5/24/00  0:00  5/24/00  12:00  5/25/00  0:00  5/25/00  12:00  5/20/00  0:00  5/26/00  12:00  5/27/00  0:00  5/27/00  12:00  5/28 /DO  0:00 

Time 

Figure  1 1 .  NIMA  &  MCS  SVN  19  Frequency  Offset  Estimates. 
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Frequency  Residual  (N1MA  &  Kalman) 


12:00  0:00  12:00  0:00  12:00  0:00  12:00  0:00  12:00  0:00  12:00 
Figure  12.  SVN  19  Frequency  Step  Impacts. 


SVN  22's  C-Field  Tune 


12:00  18:00  0:00  6:00  12:00  18:00  0:00  6:00  12:00  18:00  0:00  6:00  12:00 


Figure  13.  SVN  22  C-Field  Tune  Impacts. 
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ERD*  (Meter*)  ERDs  (Meiere) 


